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Abstract. Two sinks drain precision from higher-order flow analyses: 
(1) merging of argument values upon procedure call and (2) merging of 
return values upon procedure return. To combat the loss of precision, 
these two sinks have been addressed independently. In the case of proce- 
dure calls, abstract garbage collection reduces argument merging; while 
in the case of procedure returns, context-free approaches eliminate return 
value merging. It is natural to expect a combined analysis could enjoy the 
mutually beneficial interaction between the two approaches. The central 
contribution of this work is a direct product of abstract garbage col- 
lection with context-free analysis. The central challenge to overcome is 
the conflict between the core constraint of a pushdown system and the 
needs of garbage collection: a pushdown system can only see the top of 
the stack, yet garbage collection needs to see the entire stack during a 
collection. To make the direct product computable, we develop "stack 
summaries," a method for tracking stack properties at each control state 
in a pushdown analysis of higher-order programs. 



1 Introduction 

In higher-order flow analysis [10], merging is the enemy. Merging of flow sets 
and control-flow paths is what destroys precision. Merging occurs in two forms: 
merging on call (for arguments) and merging on return (for return-flow and 
return values). Our goal is to alleviate argument- merging while simultaneously 
eliminating return-flow merging. 

For an example of both kinds of merging, consider the following code: 

(let* ((id (lambda (x) x)) 
(a (id 3)) 
(b (id 4))) 

b) 

Flow-sensitive OCFA makes the following inferences: (1) the two instances of 
the argument x merge together: 3 and 4, and (2) the (implicit) continuations 
at applications of the identity function also merge together, causing its return 
values to merge in the variable b. 

For two decades, context-sensitivity — splitting bindings, calls and returns 
among a finite set of abstract instances — has been the "solution" to both merging 



problems. But, context-sensitivity is a finite, monotonic band-aid for an infinite, 
non-monotonic problem. Arguments ultimately merge because flow information 
accretes monotonically: once an analysis says that x may flow to y, it will never 
revoke that inference. Return-flows merge because finite flow analyses implicitly 
allocate a finite number of abstract stack pointers to continuations. 

1.1 Two solutions 

Might and Shivers developed abstract garbage collection (abstract GC) to tame 
the argument- merging problem [8] . Abstract GC assumes a small-step abstract 
interpretation [1,2] over a finite state-space. Much like concrete GC, abstract 
GC finds all of the reachable addresses in an abstract heap and reclaims any 
unreachable addresses. With abstract GC, the abstract heap no longer grows 
monotonically across a small-step transition: the same abstract address has the 
chance to get rebound to a singleton flow set over a different value many times 
over, thereby making more judicious use of the abstract resources available. For 
programs composed of (possibly recursive) tail calls and closures which never es- 
cape, abstract garbage collection delivers perfectly precise control-flow analysis. 

Pushdown control- flow analysis (PDCFA) [4] , a relative of Vardoulakis and 
Shivers's CFA2 [13], solves the return-flow problem by using the arbitrarily 
large pushdown stack to model the concrete call stack; thus, continuations never 
merge. PDCFA can reason through arbitrary levels of recursive calls. 

1.2 One problem 

Our mission is to combine the benefits of both abstract garbage collection and 
pushdown control-flow analysis: to produce an "almost complete" control-flow 
analysis which eliminates most argument merging and all continuation merging. 
The challenge is an apparent incompatibility between the two techniques. 

Abstract garbage collection must have the ability to search an entire state — 
stack included — to determine the reachable addresses. A pushdown control-flow 
analysis approximates the evaluation of a program, roughly speaking, as a push- 
down automaton. The machine states of the PDA represent the control string, 
environment, and store (heap) of the evaluator; while the stack of the PDA rep- 
resents the evaluator's stack, where each letter of the stack alphabet represents 
a continuation frame. Transitions of the PDA push and pop frames much like 
an abstract machine (e.g., the CESK machine) pushes and pops continuations. 

When a machine like the CESK machine performs garbage collection, it 
crawls the stack to determine reachable heap locations. That works because the 
stack is explicit in each machine state: it's the K component. But in a pushdown 
analysis, the abstract stack is not represented in each control state. Rather, the 
stack's structure is scattered across the transition graph between control-states. 
In more detail, the data structure accumulated during pushdown analysis is a 
transition graph where each node contains the C, E and S components and each 
edge is labeled with the change to K that happens on that transition. In order to 



recover the possible stack(s) at a node in the graph, the analysis must consider 
all the paths from the initial control state to the current state. 



1.3 Our contribution: SSCFA 

To complete our mission, we develop a new kind of higher-order pushdown-like 
control-flow analysis that includes stack summaries in its control states: SS- 
CFA. To make our contribution more general, we place constraints on stack 
summaries (in lieu of fixing them to be reachable addresses) and we let clients 
supply alternate summaries, e.g., all procedures live on the stack, whether the se- 
curity context is privileged or unprivileged. Thus, SSCFA could drive pushdown 
variants of dependence analysis or even escape analysis in addition to abstract 
garbage collection. 

The remainder of this paper is organized as follows: 

— Section 2 reviews simple preliminaries for working with pushdown systems. 

— Section 3 reviews pushdown control-flow analysis and Dyck state graphs. 

— Section 4 introduces the problem with integrating abstract garbage collection 
and pushdown analysis. 

— Section 5 informally introduces the notion of a stack summary, defines cri- 
teria for stack summarization, and gives example summarization strategies. 

— Section 6 formally defines stack-summarizing control flow- analysis. 

— Section 7 presents the computable product of stack summarizing control- flow 
analysis and abstract garbage collection. 

— Section 8 discusses related work and Section 9 concludes. 

2 Pushdown preliminaries 

In this work, we make extensive use of pushdown systems. (A pushdown au- 
tomaton is a specific kind of pushdown system.) There are many (equivalent) 
definitions of these machines in the literature, so we adapt our own definitions 
from [11]. Even those familiar with pushdown theory may want to skim this 
section to pick up our notation. 

2.1 Stack actions, stack change and stack manipulation 

Stacks are sequences over a alphabet r. Pushdown systems do much stack manip- 
ulation; to represent this more concisely, we turn stack alphabets into "action" 
sets where each character represents a stack change: push, pop or no change. 

For each character 7 in a stack alphabet r, the stack-action set r± contains 
a push (7+) and a pop (7-) character and a no-stack-change indicator (e): 



g £ r± ::= e 



7+ for each 7 6 f 
7_ for each 7 e r 



[stack unchanged] 
[pushed 7] 
[popped 7]. 



Given a string of stack actions, we can compact it into a minimal string 
describing net stack change. We do so through the operator |_-J : I± — > r± , which 
cancels out opposing adjacent push-pop stack actions: [g 7+7- g 'J = [g g 'J 
and [g e g 'J = [g g 'J , so that [g\ = g, if there are no cancellations to be made 
in the string 7. 



2.2 Pushdown systems 

A pushdown system is a triple M = (Q,T,S) where Q is a finite set of control 
states; r is a stack alphabet; and 5 C Q x T± x Q is a, transition relation. We 
use PBS to denote the class of all pushdown systems. Unlike the more widely 
known pushdown automaton, a pushdown system does not recognize a language. 

For the following definitions, let M = (Q,r,5). The configurations of this 
machine are pairs over control states and stacks: Configs(M) = Q x T* . The 
labeled transition relation (1 — >m) Q Configs(M) x T± x Configs(M) deter- 
mines whether one configuration may transition to another while performing the 
given stack action: 

(<?, 7) 1 — >m W, 7) iff (q, e, q') G 5 [no change] 

(q, i : 7) (q', 7) iff (q, i_,q') E S [pop] 

(q, 7) — (<?', 7' : 7) iff (q, i+,q') e s [push]. 

Additionally, we define: 

c 1 — >m c' iff c 1 — > 9 M c' for some stack action g, 

c 1 — > 9 M c! iff c = c 1 — >^ ci • • • c„-i 1 — c n = c' for some g = g x . . . g n , 
c 1 — ^ f c' iff c 1 — ^ c' for some g. 



2.3 Rooted pushdown systems 

A rooted pushdown system is a quadruple (Q, r, 6, qo) in which (Q, r, 5) is a 
pushdown system and qo € Q is an initial (root) state. IRPB8 is the class of all 
rooted pushdown systems. For a rooted pushdown system M — (Q, T, S, qo), we 
define a the root-reachable transition relation: 

c 1 — »m c ' 15 (?o, ()) 1 — >* M c and c 1 — >^ c'. 

In other words, the root-reachable transition relation also makes sure that the 
root control state can actually reach the transition. The root-reachable relation 
is overloaded to operate on control states: 

q 1 — » 9 M q' iff (q, 7) 1 — » 9 M (</, 7 ') for some stacks 7, 7 '. 



3 Pushdown control-flow analysis 



In this section we present the concrete and abstract semantics for the pushdown 
control-flow analysis (PDCFA) of a call-by-value A-calculus, which represents 
the core of a higher-order programming language. To simplify presentation of 
the concrete and abstract semantics, we analyze programs in A-Normal Form 
(ANF), a syntactic discipline that enforces an order of evaluation and requires 
that all arguments to a function be atomic: 



We use the CESK machine [5] to specify the semantics of ANF. We chose the 
CESK machine because it has an explicit stack. Figure 1 contains the concrete 
configuration-space of this machine. Each configuration contains a control-state 
component consisting of an expression, an environment and a store; and a con- 
tinuation/stack component. Under our abstractions, the stack component of this 
configuration-space becomes both a finite "stack summary" in abstract control 
states and a stack component in the pushdown system. (See Appendix A for a 
review of the finite-state approach and comparison to the pushdown approach.) 

PDCFA does not collapse the abstract stack into a finite structure like clas- 
sical control-flow analysis. Instead of folding the stack into the store through 
frame pointers, PDCFA distributes the stack throughout an enriched abstract 
transition system. The abstract configuration-space of pushdown control-flow 
analysis (Figure 1) is similar to concrete formulation. 

3.1 Concrete semantics and PDCFA 

Next, we define the concrete semantics of ANF and pushdown control- flow anal- 
ysis simultaneously. Specifically, we define program-to-machine injection, atomic 
expression evaluation, reachable configurations/control states, the transition re- 
lation and a resource-allocation parameter. The abstraction functions that con- 
nect the concrete configuration-space to the abstract configuration-space are 
straightforward structural abstraction functions. (Formal definitions of these ab- 
stractions can be found in Appendix B.) 

Program injection The concrete program-injection function pairs an expression 
with an empty environment, store and stack to create the initial configuration: 



/, as € Atom ::= v | lam 
lam E Lam ::= (A (v) e) 
call e Call ::= (/ ae) 

ii e Var is a set of identifiers 



e 6 Exp : 



(let ((v call)) e) 
call 



[non-tail call] 
[tail call] 
[return] 

[atomic expressions] 
[lambda terms] 
[applications] 
[variables] . 



co =X(e) = (e, [],[],()). 



c G Con) 


— State x Kont 
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Fig. 1. Configuration-space for CESK machine and pushdown control- flow analysis. 

We define two abstract injection functions — one that produces an initial ab- 
stract control state, and one that produces an initial abstract configuration. 
The control-state injector : Exp — > State pairs an expression with an empty 
environment and store to create the initial abstract state: 

^=X s "(e) = (e,D,[]). 

The configuration injector 2a : Exp — > Conf tacks on an empty stack: 

co=Xe(e) = (X f -(e),()). 

Atomic expression evaluation The atomic expression evaluator, A : Atom x Env x 
Store — Clo (or, A : Atom x Env x Store — > V(Clo) in the abstract), returns 
the value of an atomic expression in the context of an environment and a store: 

A(lam, p,a) = (lam,p) A(lam, p,a) = {(lam,p)} [closure creation] 
A(v, p, a) = a(p(v)) A(v, p, a) = a(p(v)) [variable look-up]. 

Reachable configurations The program evaluator £ : Exp — »■ V {Con}) (or, £ : 
Exp — > V(Conf) in the abstract) computes all of the configurations reachable 
from the initial configuration: 

£{e) = {c : 1(e) c} £{e) = {c : X e (e) -r* c} . 

Since the stack's depth is unbounded, the number of reachable configurations in 
both the concrete and abstract semantics could be infinite. 

Transition relation The concrete transition, c d ', and its abstract counterpart, 
c—rc', each have three rules. The first rule handles tail calls by evaluating the 



function into a closure, evaluating the argument into a value and then moving 
to the body of the A-term within the closure: 



c =(([(/ ae)],p,o-),/c) ((e,p",<r'),K), where 
([(A ( V ) e)],p') = ^(/,P^) p" = p'[v^a] 

a = alloc(v, <;) a' = a[a i-> „4(se, p, cr)] 



c =(([(/ ae)],/3,o-),K) ((e, p" ,a'), k), where 
([(A («) e)],p')d(/,p,a) p" = p>^a] 

a = alloc(v, <f) a = a U [a i-> „4(se, p, <r)]. 

In the abstract semantics, the tail-call transition is nondeterministic, since mul- 
tiple abstract closures may be invoked. 

A non-tail call builds a frame, adds it to the stack, and evaluates the call: 

(([(let ((v call)) e)j,p, <t),k) => ((call,p,a),(v,e,p) : n) 

(([(let ((v call)) e)],p, a),k) —r ((call,p,a),(v,e,p) : k). 

A function return pops the top frame of the stack and uses that frame to continue 
the computation after binding the return value to the frame's variable: 

c = ((as, p, a), (v, e, p') : k) => ((e, p", a'), k), where 
a = alloc(v, c) p" = p[v n> a] a' = a[a n> A(se, p, a)} 

c= ((se,p,a-),(v,e,p') : k') -r ((e, p", a'), k'), where 
a = alloc(v, q) p" = p'[v i-> a] o 7 = <t U [a i-> ^4(a3, p, ct)]. 

Allocation, polyvariance and context-sensitivity The address-allocation function 
is an opaque parameter in both semantics. For the concrete semantics, letting 
addresses be natural numbers suffices, and then the allocator can use the lowest 
unused address: Addr = N and alloc(v,(e, p,a,n)) = 1 + m&x(dom(cr)). The 
opacity is useful because abstract semantics also parameterize allocation — to 
provide a knob to tune the polyvariance and context-sensitivity of the resulting 
analysis — and allowing the abstract semantics to choose a particular concrete 
allocation function can simplify proofs of soundness. 



3.2 Removing the explicit stack 



The reachable subset of the abstract configuration-space for any program could 
be infinite. (There is no bound on the depth of the stack, so there are an infinite 



number of stacks and therefore an infinte number of configurations.) Conse- 
quently, the naive exploration of the reachable abstract configurations used in 
classical flow analyses may not terminate. Fortunately, because the abstract se- 
mantics describe a pushdown system, we can construct a finite (computable) 
description of the reachable configurations. Specifically, we can construct a la- 
beled transition system in which nodes are control states, and labels on edges 
denote stack change. 

We define the legal transitions in any such graph through the transition 
relation (rx) C State x Frame± x State. Three rules define this relation: one 
determining when to push, one when to pop and the last when to leave the stack 
unchanged. The labels on each transition are the stack action for the transition: 

(<?, k) —r (<f', k) = c', for any stack k [tail call] 

(<f, k) —r (j> : k) = c', for any stack k [non-tail call] 

(<T, <p : k) —r (<f', k) = c', for any stack k [return]. 

From this transition relation, we build a rooted pushdown system (Q, r, d, go) 
for a program e such that Q = States, r = Frame, 5 = (rx), and q — Z<?(e). 
The subset of this rooted pushdown system reachable over legal paths provides 
a finite description of the original configuration-space. This finite subset is a 
Dyck state graph (DSG) [4] . (A path is legal only if all of the pops match up 
with pushes; there can be unmatched pushes left over.) Several techniques can 
compute the Dyck state graph; for an efficient technique specific to PDCFA, we 
defer to our recent work [4] or the algorithm as modified in Appendix C. 



C rx <f' iff c : 
? rx <r iff c : 



q rx <;' i& c 



4 Adding abstract garbage collection to PDCFA 

In the classical version of abstract garbage collection, the abstract interpretation 
"collects" each configuration before each transition [8]. To collect a state, it 
explores the state to find the reachable abstract addresses, and then it discards 
unreachable addresses from the store, i.e., it maps them to the empty set. 

Suppose we were to add abstract garbage collection to PDCFA. At first, we 
might try collecting a control state prior to adding an edge. But, this approach 
doesn't work: to know the reachable addresses of a configuration, the analysis 
must have access to the stack paired with the control state. Unfortunately, the 
stack has been distributed across the Dyck state graph being accreted during 
the analysis. To determine the possible stacks paired with a control state, the 
analysis must consider all legal paths to that control state. 

Considering all possible paths to a control state is expensive, and troublesome 
in any event, since there could be an infinite number of such paths. A better 
solution would allow the analysis to itcratively compute properties of stacks — 
like reachable addresses — and store these summaries at individual control states. 
We call this solution stack summaries. 



5 Stack summaries 



As PDCFA constructs a DSG, it accretes reachable control states one edge at a 
time. Each time it adds a labeled edge, it is abstractly executing the transition 
relation (—r). To perform abstract garbage collection before each transition, the 
analysis must know the reachable addresses for all configurations described by 
paths to that state. To accomplish this, we add a stack summary to each con- 
trol state. A stack summary is a client-defined finite abstraction of a stack. To 
perform abstract garbagae collection, we will instantiate this summary to be the 
reachable addresses in the stack. 

A stack summary describes some property of the stack, e.g., the topmost 
frame, the reachable addresses, the privilege level of the current context. With 
respect to our analysis, the set Summary is a parameter containing all stack 
summaries, and we denote an individual stack summary as ss. A summarizing 
function, as : Stack — > Summary , walks a stack to compute a summary. Every 
stack summary regime also requires a push function parameter, push : Frame x 
Summary — > Summary, which computes the abstract effect of pushing a frame 
on a summary. There are three requirements on stack summaries: 

1. Summaries must be able to represent all possible stacks. 

2. The set of summaries must be finite. 

3. Summaries must form a lattice (Es). 

In addition, the push function must faithfully simulate concrete push; formally: 

if a(4>) C cj) and as(n) C s ss, then as(4> ■ n) E push(</>, ss). 

We can efficiently percolate stack summaries through the construction of 
a Dyck state graph, so that the algorithm never has to reconsider all paths 
to a control state. In fact, the algorithm never considers an entire path all at 
once; it propagates summaries edge-by-edge. To extend the Dyck-state-graph- 
construction algorithm, we need to consider three cases: what is the effect of 
adding a push; what is the effect of adding a pop; and what is the effect of a 
stack no-op? In this section, we describe the core of the algorithm informally but 
with sufficient detail to motivate the high-level idea. In the next section, we'll 
describe the system-space of the algorithm formally, and Appendix C contains 
the algorithm for computing a Dyck state graph with stack summaries. 

5.1 Propagating stack summaries during DSG construction 

The propagation of stack summaries across no-op and pop edges during DSG 
construction is agnostic of the particular stack summary in use. Propagation 
across push edges is fully factored into the push function parameter, push. 

The summarizing no-op operation When the Dyck state graph construction al- 
gorithm needs to propagate summaries across an edge which does not change 
the stack, the new stack summary is identical to the old sumary: when there is 
no stack change, there is no change to stack summaries. 



The summarizing pop operation The pop operation, like the no-op operation, 
can be handled without knowledge of the particular stack summary in use. In 
PDCFA, every pop transition has at least one matching push transition. The 
stack summaries after a pop are those stack summaries that can reach the new 
state with no net stack change. 

These states are easy to find, because the DSG construction algorithm main- 
tains an e-closure graph in addition to the control-state transition graph. Edges 
in the e-closure graph connect states reachable through no net stack change. 

Diagramatically, we know that the stack summary at state ^4 in the following 
is the same as the stack summary for ft: 



ft 5- <T4 




<?2 *-?3 



The summarizing push operation Pushing a frame onto a stack makes a local 
change to the stack. However, pushing a frame onto a stack may nontrivially 
change the summary. The operation push must be able to determine the new 
stack summary, so that when a push edge is introduced, the push operation 
determines the subsequent summary. 



5.2 Example: A frame-set summary 

The frame-set summary is both general and useful. The frame-set summary is 
the set of (abstract) frames currently in the stack: 

Summaryf s = V ^Frame^j . 

This summary ignores order and repetition in favor of finite size and a simple 
(subset-based) lattice: 

ss ss' iff ss C ss' . 

The summarization function for the frame set summary, ctg S : Stack — > 
Summaryf s , abstracts each frame and keeps it in a set: 

a t g(4> ll ...,cj) n ) = {a Frame (fa ),..., a Frame (<£„)}. 

The push operation push^ s : Frame x Summaryfs — > Summaryfs simply adds 
the new frame to the set: push^ s (</>, ss) = {</>} U ss. 



5.3 Example: A reachable-addresses summary 

The reachable-addresses summary is the set of all the addresses directly touch- 
able by a frame on the stack. We formally define touch through the touch func- 
tion, Tf : Frame — > Addr, which returns the addresses within the given frame: 

Tf(v, e, p) = {p(v') : v' £ free(e) - {v}} . 



The summary-space is the set of addresses: 

Summary ra = V ^Addrj . 

The order on summaries is subset inclusion: 

ss ss' iff ss C ss . 

The reachable address summarization function, a™ : Stack — > Summary ra , 
finds the reachable addresses of each abstracted frame and keeps them in a set: 

a r g{4>\, . .., 4> n ) = Tf(ctF rarnc 

The push operation push ra : Frame x Summary ra — > Summary ra adds the 
reachable addresses from the new frame to the set: 

push™(>, ss) = T f {4>) U ss. 

The reachable address summary provides the information about the stack 
needed for abstract garbage collection with pushdown control-flow analysis. 

6 SSCFA: Stack-summarizing control-flow analysis 

In the last section, we defined stack summaries and motivated their implementa- 
tion informally. In this section, we formally define the configuration-space and an 
abstract pushdown semantics for stack-summarizing control-flow analysis (SS- 
CFA). Appendix C describes a formal algorithm for creating a finite model of 
the reachable state-space for SSCFA. 

6.1 Abstract configuration-space 

The only change between the configuration-spaces for the pushdown control-flow 
analysis and the stack-summarizing control-flow analysis is that configurations 
contain stack summaries instead of stacks: 

c £ Conf = State x Summary [configurations]. 

6.2 Abstract pushdown semantics 

The abstract transition relation for SSCFA isjBimilar Jx)_the transition relation 
for PDCFA. The transition relation, (r5>) C Conf x Frame± x Conf has three 
rules. With respect to a program e, we can define a rooted pushdown system, 
M S s = (Conf, Frame, (r>),co), where c = (e, [], [],J-ss)- 



A tail call leaves the stack unchanged: 



, * e 

(([(/ ee)},p,a),ss) R5> ((e, p , a ), ss), where 
([(A ( W ) e)J,p')£A(f,p,a) p" = p'[v^a] 

a = alloc(v, q) a=ffU[fl4 A(as, p, a)]. 

A non-tail call builds a frame, adds it to the summary, and evaluates the call: 

(([(let ( (v call) ) e)], p, a), ss) RS> ((call, p, a), ss ), where 
(f> = (v,e,p) ss' — push((f>, ss). 

A function return pops the top frame off the stack. It also restores older stack 
summaries. Thus, the algorithm must know all of the abstract configurations 
on paths from the initial configuration that can reach the current configuration 
on a path whose net stack change is the the frame to be popped; we find these 
abstract configurations using the pred : Conf x Frame — > V [Conf^ function: 

pred(c>) = jc' : c i — »tf ss a ' and L^'J = <^+} ■ 
The transition rule for pop is then straightforward: 

((as, p, a), ss) RJ> ((e, p" , a'), ss'), where 
(_, ss') £ pred(c, <f) p" = p'[v i->- a] 

(v, e, p') — 4> a 1 = a U [a i-> A(as, p, a)] 

a = alloc(v, £)■ 

6.3 Soundness of stack-summarizing control-flow analysis 

The soundness of Dyck state graphs has been proved in [4] . However, the sound- 
ness of the stack summaries is provided below for the first time: 

Theorem 1. If a(c) C c, c c' and c c, then there exists & G Conf such 
that a(c') C c' and c rj> c'. 

Proof (sketch). Let c = (s,n), c' — (<;',&') and c — (<f, ss), such that a(c) C c. 
We know by theorems in [4] that there exists a state <f" £ State such that 
a(s') C <f". We also know that the first stack is subsumed by the first stack 
summary: as(n) ss. So we must prove that there exists a stack summary 
ss' £ Summary such that aj(«;') ss' and c rj> (cf", ss'). The proof continues 
with a case- wise analysis on the type of the transition as well as strong induction 
based upon the length of the path to configuration c. See Appendix D for details. 



7 SSCFA with Abstract Garbage Collection 



Having constructed a framework for iteratively synthesizing stack summaries 
during computation of a finite model for a pushdown system, we can integrate 
abstract garbage collection. In this section, we assume the "reachable addresses" 
stack summary is in use. We term this analysis SSFCFA, the product of stack- 
summarizing control-flow analysis and abstract garbage collection (also called 
TCFA). SSTCFA is a "best of both worlds" combination: it has all the argu- 
ment precision advantages of abstract garbage collection and all the return-flow 
precision advantages of PDCFA. 

As with classical abstract garbage collection, we must define what makes 
an address or value reachable. Essentially, an object is reachable if it may be 
used cither in the current configuration or in a subsequent configuration. If 
an address is reachable, all the values bound to it are also reachable. Values 
(closures and frames) reference addresses through their environments, which are 
reachable as well. Because values touch addresses and addresses touch values, 
finding reachable addresses and values amounts to a bipartite graph search. The 
concrete values of unreachable addresses will never be used again during the 
course of the computation; thus, it is safe to set the values of these addresses to 
bottom within the store. 

The reachability exploration of the store begins with the addresses that the 
current configuration c can immediately reach, called the root set, Root(c). The 

root function, Root : Conf — > V (Addr J , returns the root set for a configuration: 



where the function free : Exp — > V (Var) returns the free variables in the given 
expression. The root set contains all the addresses bound to free variables in the 
expression, e, as well as the addresses in the reachable address summary. 

The touch function, T c '■ Clo — > Addr, finds addresses referenced in closures: 
T c (lam,p) — {p(v) : v £ free (lam)}. The touching relation, (~»t,ct) : Addr — > 
Addr links addresses directly to addresses: 



With this relation, finding all reachable addresses of a configuration c becomes 
the transitive closure of the touching relation: 



Finally, we define the abstract garbage collector itself, AGC : Conf — > Con/, 
which simply restricts the store to the reachable addresses: 3 




Root((e, p, a), ss) = ss U {p(v) : v £ /ree(e)} , 



a ~~~*T,a o! iff a! £ Tc(val) and vol £ a(a). 



TZ(c) = {a : a a and a £ Root(c)} . 



AGC(c) = (e, p, a\1Z(c), ss), where c = (e, p, a, ss). 



3 We define function restriction, f\X, so that f\X = \x.if x £ X then f(x) else _L. 



The abstract transition relation for SSTCFA, (^>agc) Q Conf x Conf , 
needed for stack-summarizing control-flow analysis with abstract garbage col- 
lection extends the abstract transition relation to collect before each transition: 

c ^>agc c iff AGC(c) Rj> c. 

The soundness theorems and their proofs for classical abstract garbage collection 
are in Chapter 6 of [7] ; they adapt readily to our pushdown framework. 

8 Related Work 

Stack summarization, the central contribution of this paper, overcomes the ap- 
parent incompatibilities of two orthogonal anti-merging techniques designed to 
improve precision: abstract garbage collection [8] and pushdown control-flow 
analysis [4, 13]. As such, this work directly builds upon both techniques, as well 
as classical control-flow analysis [10], abstract machines [5], and abstract inter- 
pretation [1,2] in general. 

Abstract garbage collection [8, 12] curbs argument-merging, but it has not 
yet been applied to anything beyond classical control-flow analysis. 

Vardoulakis and Shivcrs's CFA2 [13] is the precursor to the pushdown control- 
flow analysis [4] presented in Section 3. CFA2 is a table-driven summarization 
algorithm that exploits the balanced nature of calls and returns to improve 
return-flow precision in a control-flow analysis. While CFA2 uses a concept 
called "summarization," it is a summarization of execution paths of the analysis, 
roughly equivalent to Dyck state graphs rather than our stack summaries. 

In terms of recovering precision, pushdown control-flow analysis [4] is the 
dual to abstract garbage collection: it focuses on the global interactions of con- 
figurations via transitions to precisely match push-pop/call-return, thereby elim- 
inating all return-flow merging. However, pushdown control-flow analysis does 
nothing to improve argument merging. 

In the context of first-order languages, pushdown approaches to analysis are 
well-established. Reps et al. [9] uses a summarization algorithm to compute a 
Dyck-state-graph-like solution. Debray and Proebsting [3] develop an analysis 
with perfect return-flow in the presence of tail calls. For higher-order languages, 
finite-state approaches approximating the pushdown precision of return-flow 
have been explored by Midtgaard and Jensen [6] and Van Horn and Might [12]. 
Our work extends the pushdown approach to higher-order languages with tail 
calls, and produces stack summaries to enable abstract garbage collection. 

9 Conclusion 

We presented SSFCFA, a synergistic fusion of pushdown analysis and abstract 
garbage collection to combat the twin sinks for precision in higher-order flow 
analysis: merging in arguments, and merging in return-flow. In order to create 
SSTCFA, we had to first create SSCFA, a pushdown control-flow analysis for 



higher-order programs capable of iteratively synthesizing summaries of stack 
properties; in this case, we required a summary of reachable addresses on the 
stack. Abstract garbage collection combats merging in arguments by eliminating 
monotonicity for the abstract store; pushdown analysis eliminates the loss in 
return-flow precision by simulating the concrete call stack with a pushdown 
stack, thereby properly matching returns to call. 
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A Classical control-flow analysis 



This section presents traditional control-flow analysis for reference and com- 
parison with pushdown and stack-summarizing control flow analysis. Classical 
control- flow analysis for ANF operates over the abstract state-space in Figure 2. 
Our classical formulation follows Van Horn and Might's technique of allocating 
abstract continuations in the store, as opposed to stacking them [12]. 



c 6 Conf 


= State x Addr 


[configurations 


f G State 


= Exp x Env x Store 


[states] 


p € Env 


= Var Addr 


[environments] 


a £ Store 


= Addr ->■ V (Clo U FrameJ 


[stores] 


do e Clo 


— Lam x Env 


[closures] 


<f> € Frame 


— Var x Exp x Env x Arfdr 


[stack frames] 


fp,a £ Addr 


is a finite set of addresses 


[addresses] 



Fig. 2. Abstract configuration-space for classical control-flow analysis. 



To complete the abstract semantics we need to define program injection, 
atomic expression evaluation, reachable configurations, transition relation, ad- 
dress allocation, and abstraction function: 

Program injection The abstract injection function I : Exp — > Conf pairs an 
expression with an empty environment, an empty store and an empty stack to 
create the initial abstract configuration: 

c =X(e) = (e, [],[], null), 

where null is an address bound to nothing in the store, thus representing an 
empty stack. 

Atomic expression evaluation The abstract atomic expression evaluator, A : 
Atom x Env x Store — > V{Glo U Frame), returns the value of an atomic expression 
or a stack frame in the context of an environment and a store; note how it returns 
a set: 



A(lam, p, a) = {(lam, p)} [closure creation] 

A(v,p,cr) = &(p(v)) [variable look-up]. 



Reachable configurations The abstract program evaluator £ : Exp — > V(Conf) 
returns all of the configurations reachable from the initial configuration: 



;(e) = {c : 1(e) ->* c} . 



Transition relation The abstract transition relation (~-») C Con/ x Con/ has 
three rules, two of which have become nondctcrministic. A tail call may fork 
because there could be multiple abstract closures that it is invoking: 



(([(/ ae)},P,o-),rp) ~* ((e, p", &'), fp), where 
([(A (v) e)j,p')eA(f,p,a) 

a = alloc(v, <f) 
p" = p'[v h-> o] 
j' = ffU[o^ ,A(a3, p, it)]. 

The partial order for stores is: 

(aUa')(a) = a(a) LI a' (a). 
A non-tail call builds a frame, adds it to the store, and evaluates the call: 



(([(let ((v call)) e)j,p,a),fp) ~~> ((call, p,a),fp'), where 

fp' — alloc(v, <f) 
a' = a U [fp' i— > (v, e, p, fp)] . 

A function return may fork because there could be multiple frames bound to the 
current return pointer: 

((se,p,a),fp) ~> ((e,p",a'),fp'), where 
(v,e,p',fp) G o-(fp) 

a = alloc(v, <f) 
p" =j5'[«4 a] 
ct' = a U [a i->- ^4(£C, p, a)]. 

Allocation, polyvariance and context-sensitivity In the abstract semantics, the 
abstract allocation function alloc : Var x State — > Addr determines the poly- 
variance of the analysis (and, by extension, its context-sensitivity). The abstract 
allocation function is overloaded to assign return pointers (addresses) to abstract 

stack frames: alloc : Frame x State Addr. In a control-flow analysis, polyvari- 
ance literally refers to the number of abstract addresses (variants) there are for 
each variable. 



Abstraction function The abstraction function (a) converts any structure from 
the concrete semantics (Figure 1) into an abstract form of the same structure 
(Figure 2). (The abstraction function is defined in Appendix B. While not specif- 
ically defined for these semantics, the abstraction function there can easily be 
modified to work with return pointers.) 

Comparison to pushdown control-flow analysis The abstract semantics of push- 
down control-flow analysis are similar to those of the abstract semantics for 
classical control- flow analysis (Figure 2). However, the few key differences are 
worth noting. 

Foremost, we are not working with the configuration-space directly; rather 
we deal with the control-state-space. Hence, a configuration is now defined as a 
state and a stack paired together. The results of pushdown control-flow analysis 
are rooted pushdown systems rather than nondeterminisitic finite automata. A 
rooted pushdown system handles the stack and configurations implicitly, so we 
use the control-state-space instead of the configuration-space. 

The next change is that the store only contains bindings from addresses to 
closures, instead of from addresses to closures and frames. The abstraction of 
the store creates imprecision. By keeping the frames out of the store (and in a 
precise structure) we avoid this imprecision for continuations. 

The final difference is that frames no longer contain return pointers. Again, 
this is because the enriched abstract transition system encapsulates that infor- 
mation precisely. 



B Abstraction Functions 



This section defines the abstraction functions used throughout this paper. In 
particular, the following abstraction functions links the concrete and the abstract 
configuration-spaces in Section 3. The abstraction function recurs structurally: 



a(?,/c) 

Ot Stated, p,(j) 
dEnv(p)(v) 

astore(o-)(a) 
a C io(lam, p) 

CtKontd&l, ■ ■ -An)) 

(v,e,p) 



{e,a En v{p),astore{o-)) 
a A ddr(p(v)) 

\_\ a C io(o-(a)) 



&Addr(a)=a 



{(lam,a En v(p))} 

, Ct Frame \ 

(v, e, a En v(p)) 



[configuration abstraction] 
[state abstraction] 
[environment abstraction] 
[store abstraction] 

[closure abstraction] 
f> n )) [stack abstraction] 
[frame abstraction]. 



Just as address-allocation is a parameter, the address abstraction function, 
(XAddr '■ Addr — > Addr, is a parameter for the abstract semantics. 

For Sections 5, 6, and 7, the abstraction function for configurations is: 



a(<;, k) — {otstate^), as{K)) [configuration abstraction], 



where the stack summarization function, as, is a parameter as described in 
Section 5. 

C Building a Dyck configuration graph 
C.l Building a Dyck state graph for PDCFA 

A fixed-point approach to building Dyck state graphs for PDCFA is best pre- 
sented in [4]. The algorithm in Figure 3 is a similar iterative algorithm, but it 
is formulated for stack-summarizing control- flow analysis (Section 6). The un- 
derlying approaches are similar. In fact, for the algorithm in Figure 3, replacing 
configurations with states and switching the transition relation used throughout 
to the transition relation of Section 3 (rv) is enough to convert the algorithm to 
build standard Dyck state graphs. The main difference is that the algorithm pre- 
sented here examines a single state, transition, or shortcut edge each iteration, 
whereas the fixed-point algorithm examines the entire frontier each iteration. 

C.2 Building a Dyck state graph for SSCFA 

The algorithm in Figure 3 builds the Dyck configuration graph and the e-closure 
graph for a given program e. It uses the worklists, AS, AE, and AH, to maintain 
the frontier of unexplored configurations, transitions, and shortcut edges respec- 
tively. The while loop runs until all the worklists are empty, which is exactly 
when everything reachable has been explored. Each iteration of the while loop, 
explores one previously unexplored shortcut edge, transition, or configuration. 

Each new configuration, transition, and shortcut edge can imply other config- 
urations, transitions, and shortcut edges globally. Thus, after each configuration, 
transition, or shortcut edge is explored, the implied configurations, transitions, 
and shortcut edges are added to the worklists. 

The procedure addShort finds all the configurations, transitions, and shortcut 
edges implied by the given shortcut edge. The only new transitions implied by 
a shortcut edge are pop transitions that are enabled by a new push transition. 
The only new configurations are those in the newly implied pop transitions. 

The procedure addEdge finds all the configurations, transitions, and shortcut 
edges implied by the given transition. There are three types of transitions: First, 
there are no-op (e) transitions, which immediately become shortcut edges, and 
so are added to the e-closure graph and are expanded. Next, there are push 
transitions, which imply new pop transitions (and configurations from these pop 
transitions) as well as new shortcut edges (from pre-existing pop transitions). 
Finally, there are pop transitions, which imply only new new shortcut edges from 
pre-existing push transitions. 

The last procedure Explore finds all the configurations, transitions, and 
shortcut edges implied by the given configuration. A configuration cannot im- 
ply any shortcut edges directly. However, a configuration can imply new no-op, 
push, or pop transitions as well as new configurations from these transitions. 



procedure BmldDyck(e) 

co <- i e (e); G <- (0, E, 0, co); G e <- (0, 0); AS <- {c }; AE <- 0; AH <- 
while (AS ± or AE ^ or AH / 0) 
if (AH / 0), let (£,£') G AH 

(AS', AE', AH') <- addShort(G, G e )(c >-> c) 

(S*, H) <- G E 

G^(S,f/U{(c,c')}) 

(AS, AE, AH) <- (AS U AS', AE U AE', AH u AH' - {(c, c')}) 
else if (AE / 0), let (c,g,c') G AE 

(AS' , AE' , AH') <- addEdge(G,G e )(c^ 9 c') 
(S, r, E, c ) <— G 
G^(S,r,£U{(c, ff ,c')},c ) 

(AS, AE, AH) <- (AS U AS", AE U AE' - {(c, g, c')}, AH U AH') 
else if (AS / 0), let c G AS 

(AS", AE', AH') <- Explore(G, G € )(c) 

(S,r,E,c )<-G 

(S, H) <- G £ 

(G, G e ) <- ((5 U {c}, E, E, co), (5 U {£}, H)) 
(AS, AE, AH) <- (AS U AS' - {£}, AE U AE', AH U AH') 
return G, G e 

procedure addShort(G,G t )(c,c.') 
(S,r,E,c Q )<-G;(S,H)<-G e 

AE <- |(c',<?L,c 2 ) : (ci,0+,c) G E and c' RJ>^- c 2 | 

AS<- |c 2 : (ci,^_,c 2 ) G AE| 
AH<r- {(ci,c') : (ci,c) G H} 

U{(c,c 2 ) : (c',c 2 ) G H} 

U{(ci,c 2 ) : (ci,c), (c',c 2 ) G H"} 
return AS - S, AE - E, AH - H 

procedure addEdge(G,G t )(c^ s c') 
(5*, E, E, co) <— G; (S,H)<-G e 

if (g = e) return addShort(G, (S, H U {(c, c')}))(c, c') 
else if (g = 4>+) 

AE 4- |ci >-►*- £2 : c' m ci £ and 6i R3>^- c 2 | 

AS <- |c 2 : ci c 2 G AE| 

AH <- jc >-> c 2 : c' >-> ci G H and £i c 2 G E j 
return AS — S, AE — E, AH — H 
else if (g = cf>-) 

return 0, 0, {ci ^ c' : c 2 ^ c G ff and ci ^+ c 2 G e| — H 

procedure Explore(G,G t )(c) 
(S,r,E,c ) G; (S,H) <- G e 

return {£' : c«> 9 &'} - S, {(c, g, £') : czi> 9 c} - E, 

Fig. 3. Algorithm to build a Dyck configuration graph. Procedures addShort, addEdge 
and Explore determine what configurations, transitions, and shortcut edges are implied 
by a given shortcut edge, transition, or configuration, respectively. 



C.3 Building a Dyck state graph for SSrCFA 



Finally, we let the procedures of Figure 3 use this transition relation (rJ>jgc) and 
the reachable address push function push™. Now the procedure BuildDyck 
of Figure 3 computes stack-summarizing control-flow analysis with abstract 
garbage collection soundly. 



D Proofs 



Proof (of Theorem 1). Without loss of generality, assume that the path from 
the initial configuration cq to c is length n, so the path to the new configuration 
d is n + 1 transitions from the initial configuration. The inductive hypothesis is 
that the theorem holds for all paths of length less than or equal to n. So far the 
scenario can be diagrammed as below: 



co 



=?• c 



We now have three cases depending on what g is: 

- c«> £ c' = (<?",&') 

No change is made to the stack in the concrete, thus the stacks are equal: 
k = k'. Likewise, no change is made in the abstract, thus: ss — ss . Since the 
first stack is subsumed by the first stack summary, the second stack must be 
subsumed by the second stack summary: as(n') Cs ss'. 

- c & = (<?", is') 

A frame <fr, such that a(<fi) C <p 1 must be pushed onto the stack in the 
concrete, so the stacks are related thusly: <f> : k = k'. Likewise, the stack 
summaries are so related: push(</>, ss) Qs ss'. By the constraint on all push 
operations: as(<fr ■ k) Qs push(0, asi^)). We can make the following re- 
placements: (Xs(k') push((/>, ss). By the definition of the transitive rela- 
tion (r*>): ss' = push(0, ss). Finally we have: as(n') C s ss' . 

- £ & = (<?", is') 

A frame <f>, such that ce(<p) C <f>, must be popped from the stack in the con- 
crete, so the stacks are related like this: n = <j> : «/. We know that configura- 
tion c is reachable from the initial configuration, which has an empty stack. 
Since the transition from the configuration pops off a frame <j), it does not cur- 
rently have an empty stack. So there exists a path, 

such that the net of the stack actions after the push, [g\, is empty. Let 
ci = (?i,Ki). Since the net of the stack actions is empty, the stack at the 
configuration before the last previously unmatched push, m, is identical to 
the stack after the current pop, n': K\ = k' . 



By the inductive hypothesis, there is a path through the Dyck configuration 
graph that parallels and mimics the path above. Thus, there is a configura- 
tion ci = (<fi, sbi) such that a(c\) C c\. Also by this path, there is a sub-path 
from the configuration ci to the new configuration c' that makes no changes 
to the stack. Therefore, there is a shortcut edge between these two config- 
urations Ci and c'. The proof of the first case for shortcut edges works for 
no-op transitions. Thus the stack summaries at these two configurations are 
the same: ss\ — ss' . 
The current situation is as follows: 




Since the configuration before the last previously unmatched push, c\ is 
subsumed by its equivalent in the Dyck configuration graph, c\ , its stack is 
subsumed by the stack summary of configuration ci: (Xs{ki) ssi- Since 
this stack and this stack summary are identical to the stack k' and the stack 
summary ss' respectively, we have: as(n') t=s ss' . □ 



